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METHOD AND APPARATUS FOR KEEPING TRACK OF 
PROGRAM INDEXES IN AN INTERACTIVE DELIVERY SYSTEM 

BACKGROUND OF THE INVENTION 

The present invention relates to communications systems in general. More 
specifically, the invention relates to techniques to efficiently deliver interactive program 
guide (IPG) in a server-centric system. 

Over the past few years, the television industry has seen a transformation 
in a variety of techniques by which its programming is distributed to consumers. Cable 
television systems are doubling or even tripling system bandwidth with the migration to 
hybrid fiber coax (HFC) cable plant. Customers unwilling to subscribe to local cable 
systems have switched in high numbers to direct broadcast satellite (DBS) systems. And, 
a variety of other approaches have been attempted focusing primarily on high bandwidth 
digital technologies, intelligent two-way set top terminals, or other methods of trying to 
offer service differentiated from standard cable and over-the-air broadcast systems. 

With this increase in bandwidth, the number of programming choices has 
also increased. Leveraging off the availability of more intelligent set top terminals, 
several companies such as Starsight Telecast Inc. and TV Guide, Inc. have developed 
elaborate systems for providing an interactive listing of a vast array of channel offerings, 
expanded textual information about individual programs, and the ability to look forward 
to plan television viewing as much as several weeks in advance. 

With this increase in the quantity of programming, it is a challenge to 
deliver program guide data to viewers in an efficient and effective manner. A large 
amount of resources (e.g., bandwidth) would normally be needed to continually transmit, 
for example, two weeks of programming for 200 channels. Therefore, efficient and 
effective techniques to deliver interactive program guide to a large number of viewers are 
highly desirable. 

Moreover, the increased bandwidth has allowed service providers to offer 
various services such as regular programming, pay-per-view (PPV), video-on-demand 
(V OD), music channels, and so on. The large amount of programming offered by each of 
these services typically necessitates the use of a separate user interface especially adopted 
for the service. As more services are provided and the complexity of these services 
increases, the user interfaces becomes more complicated to implement and for users to 
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navigate. Thus, an integrated user interface that supports these various services, 
especially interactive program guide (IPG) and VOD, are highly desirable. 



SUMMARY OF THE INVENTION 

5 The present invention provides techniques (a "roster") to keep track of 

program indexes and which can be advantageously used to support an interactive program 
guide (IPG) delivery system. The IPG can be provided via a number of IPG pages and 
each IPG page can be defined with a number of regions (or portions). The non-redundant 
regions for the IPG pages can be encoded, and some of the encoded regions can be 

10 continually transmitted (i.e., broadcast) and some others can be transmitted as requested 
(i.e., demand-cast). To implement a bandwidth efficient demand-cast system, only the 
necessary regions not currently received at a terminal are requested (as oppose to entire 
pages), and the head-end transmits only the requested regions. 

An aspect of the invention provides indexing techniques to maintain track 

15 of which regions of which IPG pages are currently received at a terminal from the head- 
end. These techniques allow the terminal to determine whether a selected IPG is 
currently received and available, which regions are to be assembled together to generate 
the selected page, and which packet identifiers (PIDs) are to be processed to recover the 
needed regions. 

20 An embodiment of the invention provides a method for maintaining 

records of information related to IPG, with the IPG being provided via a number of IPG 
pages, hi accordance with the method, a "roster" is formed which includes a number of 
record elements with each record element being associated with a respective IPG page 
received at a terminal. Each record includes a page ID field that specifically identifies the 

25 associated IPG page, and this page ID field can identify a particular PID for a guide 
listing for the IPG page. A number of other fields may also be included in each record 
element such as, for example, fields for a video PID, a data PID, or some other 
information for the associated IPG page, or a combination thereof. The roster can be 
updated to reflect changes (i.e., insertions and deletions) in the IPG pages received at the 

30 terminal. 

The invention further provides other methods and system elements (i.e., 
terminal and server) that implement various aspects, embodiments, and features of the 
invention, as described in further detail below. 
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The foregoing, together with other aspects of this invention, will become 
more apparent when referring to the following specification, claims, and accompanying 
drawings. 



5 BRIEF DESCRIPTION OF THE DRAWINGS 

The teachings of the invention can be readily understood by considering 
the following detailed description in conjunction with the accompanying drawings. 

FIG. 1 is a diagram of an illustrative communications network for 
distributing video sequences to a number of terminals in accordance with an embodiment 
10 of the invention; 

FIGS. 2-6 are diagrams of various methods and topologies for demand- 
casting interactive program guide (IPG) pages in accordance with embodiments of the 
invention; 

FIGS. 2 A and 2B are respectively a flow diagram and a topology for a first 
1 5 push method for demand-casting IPG pages in accordance with an embodiment of the 
invention; 

FIGS. 3A and 3B are respectively a flow diagram and a topology for a 
second push method for demand-casting IPG pages in accordance with an embodiment of 
the invention; 

« 20 FIGS. 4 A and 4B are respectively a flow diagram and a topology for a first 

pull method for demand-casting IPG pages in accordance with an embodiment of the 
invention; 

FIGS. 5A and 5B are respectively a flow diagram and a topology for a 
second pull method for demand-casting IPG pages in accordance with an embodiment of 
25 the invention; 

FIGS. 6A and 6B are respectively a flow diagram and a topology for a 
third pull method for demand-casting IPG pages in accordance with an embodiment of 
the invention; 

FIG. 6C is a flow diagram showing a method for terminating (or 
30 continuing) demand-casts in accordance with the third pull method; 

FIG. 7 is a diagram of a two-way system for efficient delivery of demand- 
cast video sequences in accordance with an embodiment of the invention; 
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FIG. 8 depicts an example of a set of IPG pages for continual broadcast 
and other IPG pages for demand-cast in accordance with an embodiment of the invention; 

FIG. 9 is an example of one picture taken from a video sequence that can 
be encoded using the invention; 
5 FIGS. 10-13 are block diagrams of first, second, third, and fourth 

architectures, respectively, for managing delivery of video sequences of an interactive 
program guide in accordance with embodiments of the invention; 

FIG. 14 is a block diagram of an embodiment of set top terminal (STT) 
1408 suitable for producing an IPG page and supporting various aspects of the invention; 
10 FIGS. 15A-15D are diagrams of an embodiment of the messaging between 

the terminal, the session manager, and the transport stream generator; 

FIG. 16 is a diagram of an example showing the status of active demand- 
cast streams in an IPG multiplex; 

FIGS. 17A and 17B are diagrams illustrating various scenarios for 
1 5 activation and release of a demand-cast stream; 

FIG. 18A is a diagram of an embodiment of a message format that can be 
used to send a demand-cast request; 

FIGS. 18B through 18D are diagrams of an embodiment of message 
formats that can be used to send requests for a particular guide listing for a guide region, a 
20 particular video for a video region, and an icon region, respectively; and 

FIGS. 19A and 19B are diagrams of two embodiments of a roster that can 
be used to maintain track of IPG pages received at the terminal. 

To facilitate understanding, identical reference numerals have been used, 
where possible, to designate identical elements that are common within a figure. 

25 

DESCRIPTION OF THE SPECIFIC EMBODIMENTS 

A. ILLUSTRATIVE COMMUNICATIONS NETWORK 

FIG. 1 is a diagram of an illustrative communications network 100 for 
30 distributing video sequences to a number of terminals in accordance with an embodiment 
of the invention. Communications network 100 may be a cable distribution network, but 
other types of distribution networks may also be used and are within the spirit and scope 
of the invention. 
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As shown in FIG. 1, communications network 100 includes one or more 
head-ends (HE) 102, one or more centers for local neighborhood equipment (LNE) 104, a 
number of distribution nodes 106, and a number of terminals 108. Local neighborhood 
equipment 104 may be located, for example, at remote hubs of a cable distribution 
5 network. Terminals 108 maybe user terminals, interactive set-top terminals (STT), or 
other devices with interactive functionalities. 

B. EXAMPLE METHODS AND TOPOLOGIES 

As used herein, "demand-cast" refers to the process of managing and 
1 0 delivering content to one or more users in response to user demand for the content. 

"Broadcast" refers to the process of managing and delivering content to a number of users 
on a continual basis. "PointCast" refers to the process of managing and delivering content 
to a particular user. And "Narrowcast" refers to the process of managing and delivering 
content to a group of users. 
15 FIGS. 2-6 are diagrams of various methods and topologies for demand- 

casting interactive program guide (IPG) pages. These methods and topologies are 
presented for purposes of edification and are not meant to limit the scope of the invention. 

1. First Push Method for Demand-cast 

20 FIG. 2A is a flow diagram showing a first push method 200 for demand- 

casting IPG pages in accordance with an embodiment of the invention. As described 
below, method 200 includes four steps. 

In a first step 202, a first set of IPG pages to be broadcast is 
predetermined. The first set of IPG pages may comprise video sequences, for example, 

25 for a current time period. For instance, if the current time is 1 : 07 pm, then the current 
time period may include programming from 1 :00 pm to 2:30 pm, assuming a 90-minute 
time period. 

In a second step 204, a second set of IPG pages to be broadcast is 
predetermined. The second set of IPG pages may comprise video sequences, for 
30 example, for a prime time period. Such prime time period is a time period during which a 
large number of viewers typically watch TV programming. For example, the prime time 
period may include programming from 6:00 pm to 9:00 pm. 
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In a third step 206, the bandwidth to broadcast the first and second sets of 
IPG pages is allocated by the distribution system for that purpose. For example, as 
described below in more detail, a bandwidth manager (BWM) within head-end 102 
and/or local neighborhood equipment 104 allocates the necessary bandwidth within the 
5 in-band network to broadcast the first and second sets of IPG pages to the terminals. If 
the first and second sets overlap, then only the non-redundant video sequences need to be 
broadcast, and only enough bandwidth to broadcast the non-redundant video sequences 
needs to be allocated. Such situation may occur, for example, when the current time 
period overlaps the prime time period. 

10 hi a fourth step 208, the IPG pages of the first and second sets are 

broadcast to terminals 1 08 within the broadcast range. The broadcast range may 
comprise all terminals 108 downstream from head-end 102 or local neighborhood 
equipment 104. Only non-redundant content needs to be broadcast, and the broadcast is 
achieved within the allocated in-band bandwidth. 

15 FIG. 2B depicts a first push topology 250 for demand-casting IPG pages in 

accordance with an embodiment of the invention. Topology 250 corresponds to the first 
push method 200 of FIG. 2A. As shown in FIG. 2B, the IPG pages are transmitted from 
head-end 102 or local neighborhood equipment 104 downstream within communications 
network 100. As shown in FIG. 2B, the broadcast is "pushed" from head-end 102 or 

20 local neighborhood equipment 104 to distribution nodes 106 and finally to a number of 
terminals 108. 

2. Second Push Method for Demand-cast 

FIG. 3 A is a flow diagram showing a second push method 300 for 
25 demand-casting IPG pages in accordance with an embodiment of the invention. As 
described below, method 300 includes three steps. 

In a first step 302, one or more IPG pages are selected to be narrowcast to 
a group of terminals 352. For example, the group of terminals may be a group 
comprising a high concentration of users with a particular ethnicity or special interest, and 
30 the selected IPG page(s) may comprise programming targeted to that ethnic or special 
interest group. As another example, the group of terminals may comprise terminals in a 
school campus or business, and the selected IPG page(s) may comprise class instruction 
or other targeted material. The group of terminals may include terminals in one 
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geographic area or terminals dispersed among different geographic areas but linked, for 
example, via a network group address. 

In a second step 304, the bandwidth to narrowcast the selected IPG page(s) 
is allocated by the distribution system for that purpose. For example, as described below 
5 in more detail, the bandwidth manager (BWM) within head-end 102 and/or local 
neighborhood equipment 104 allocates the necessary bandwidth within the in-band 
network to narrowcast the selected IPG page(s) to the group of terminals. If the requested 
IPG page(s) are already being broadcast as shown in Figs. 2A and 2B, then no additional 
bandwidth for a narrowcast needs be allocated. 

10 In a third step 306, the selected IPG page(s) are narrowcast to the group of 

terminals. The narrowcast needs only to be received by terminals within the group of 
terminals 352 and does not need to be received by other terminals. The narrowcast is sent 
downstream from head-end 102 or local neighborhood equipment 104 to the group of 
terminals. The narrowcast is achieved within the allocated in-band bandwidth. If the 

1 5 requested IPG page(s) are already being broadcast as shown in Figs. 2A and 2B, then the 
narrowcast needs not be performed. 

FIG. 3B depicts a second push topology 350 for demand-casting IPG 
pages in accordance with an embodiment of the invention. Topology 350 corresponds to 
the second push method 300 of FIG. 3 A. As shown in FIG. 3B, the IPG page(s) are 

20 transmitted from head-end 102 or local neighborhood equipment 104 downstream within 
communications network 100. As shown in FIG. 3B, the narrowcast is pushed from 
head-end 102 or local neighborhood equipment 104 to one or more distribution nodes 106 
and finally to the terminals within group of terminals 352. 

25 3. First Pull Method for Demand-cast 

FIG. 4A is a flow diagram showing a first pull method 400 for demand- 
casting IPG pages in accordance with an embodiment of the invention. As described 
below, method 400 includes three steps. 

In a first step 402, a request for an IPG page is received from a terminal 
30 108. The request is transmitted upstream from terminal 108 to head-end 102 or local 
neighborhood equipment 104 via communications network 100. The upstream 
transmission may be achieved via an out-of-band network or, alternatively, via an in-band 
network. Such request from the requesting terminal may comprise, for example, a look- 
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ahead request for programming for a time period ahead of the current time period. For a 
system where one or more IPG pages are already broadcast as shown in Figs. 2A and 2B, 
the requesting terminal may first check to see whether or not the requested IPG page is 
already being broadcast before transmitting the request upstream. 
5 In a second step 404, the bandwidth to pointcast the requested IPG page is 

allocated by the distribution system for that purpose. For example, as described in more 
detail below, the bandwidth manager within head-end 102 and/or local neighborhood 
equipment 104 may allocate the necessary bandwidth within the in-band network to 
pointcast the requested IPG page to the requesting terminal. The allocation is performed 

10 if sufficient system resources are available to establish a pointcast session. Moreover, if 
the requested IPG page is already being broadcast as shown in Figs. 2A and 2B, then no 
additional bandwidth for a pointcast needs be allocated. 

In a third step 406, the requested IPG page is pointcast to the requesting 
terminal. The pointcast needs only to be received by the requesting terminal and does not 

1 5 need to be received by other terminals. The pointcast is sent downstream from head-end 
102 or local neighborhood equipment 104 to the requesting terminal. The pointcast, if 
necessary, is achieved within the allocated in-band bandwidth. If the requested IPG page 
is already being broadcast as shown in Figs. 2A and 2B, then the pointcast needs not be 
performed. 

20 FIG. 4B depicts a first pull topology 450 for demand-casting IPG pages in 

accordance with an embodiment of the invention. Topology 450 corresponds to first pull 
method 400 shown in FIG. 4A. As shown in FIG. 4B, the request is transmitted upstream 
from the requesting terminal 108 to head-end 102 or local neighborhood equipment 104 
via communications network 100. Subsequently, the requested IPG page is pointcast 

25 downstream from head-end 102 or local neighborhood equipment 104 to the requesting 
terminal via communications network 100. 

4. Second Pull Method for Demand-cast 

FIG. 5 A is a flow diagram showing a second pull method 500 for demand- 
30 casting IPG pages in accordance with an embodiment of the invention. As described 
below, method 500 includes three steps. 

In a first step 502, a request for an IPG page is received from a requesting 
terminal 552. The request is transmitted upstream from requesting terminal 552 to head- 
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end 102 or local neighborhood equipment 104 via communications network 100. The 
upstream transmission may be achieved via an out-of-band network or, alternatively, via 
an in-band network. Such request may comprise, for example, a look-ahead request for 
special interest programming available for a future time period ahead of the current time 
5 period. For a system where a set or sets of IPG pages are already being broadcast as 

shown in Figs. 2A and 2B, requesting terminal 552 may first check to determine whether 
or not the requested IPG page is already being broadcast before transmitting the request 
upstream. 

In a second step 504, the bandwidth to narrowcast the requested IPG page 

10 is allocated by the distribution system for that purpose. For example, as described below 
in relation to Figs. 7 and 8, the bandwidth manager within head-end 102 and/or local 
neighborhood equipment 104 may allocate the necessary bandwidth within the in-band 
network to narrowcast the requested IPG page to a group of terminals 554 that includes 
requesting terminal 552. The allocation is performed if sufficient system resources are 

1 5 available to establish a narrowcast session. If the requested IPG page is already being 
broadcast as shown in Figs. 2A and 2B, then no additional bandwidth for a pointcast 
needs to be allocated. The group of terminals 554 may include terminals in one 
geographic area or terminals dispersed among different geographic areas but linked, for 
example, via a network group address. 

20 In a third step 506, the requested IPG page is narrowcast to group of 

terminals 554. The narrowcast needs only to be received by the terminals within group of 
terminals 554 and does not need to be received by other terminals. The narrowcast is sent 
downstream from head-end 102 or local neighborhood equipment 104 to group of 
terminals 554. The narrowcast is achieved within the allocated in-band bandwidth. If the 

25 requested IPG page is already being broadcast as shown in Figs. 2A and 2B, then the 
narrowcast needs not be performed. 

FIG. 5B depicts a second pull topology 550 for demand-casting IPG pages 
in accordance with an embodiment of the invention. Topology 550 corresponds to second 
pull method 500 shown in FIG. 5 A. As shown in FIG. 5B, the request is transmitted 

30 upstream from requesting terminal 552 to head-end 102 or local neighborhood equipment 
104 via communications network 100. Subsequently, the requested IPG page is 
narrowcast downstream from head-end 102 or local neighborhood equipment 104 to 
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group of terminals 554, which includes requesting terminal 552, via communications 
network 100. 

5. Third Pull Method for Demand-cast 

5 FIG. 6 A is a flow diagram showing a third pull method 600 for demand- 

casting IPG pages in accordance with an embodiment of the invention. As described 
below, method 600 includes six steps. 

In a first step 602, a request for an IPG page is received from a first 
terminal 652. The request is transmitted upstream from first terminal 652 to head-end 

10 102 or local neighborhood equipment 104 via communications network 100. The 

upstream transmission maybe achieved via an out-of-band network or, alternatively, via 
an in-band network. Such request from first terminal 652 may comprise, for example, a 
look-ahead request for programming for a future time period ahead of the current time 
period. For a system where one or more IPG pages are already being broadcast as shown 

15 in Figs. 2 A and 2B, first terminal 652 may first check to see whether or not the requested 
IPG page is already being broadcast before transmitting the request upstream. 

In a second step 604, a stream 656 may be assigned by the distribution 
system to pointcast the requested IPG page. The assignment is performed if sufficient 
system resources are available to establish a pointcast session. For example, as described 

20 below in more detail, the bandwidth manager within head-end 1 02 and/or local 

neighborhood equipment 104 may determine that sufficient resources are available to 
assign stream 656 to pointcast the requested IPG page to first terminal 652. The stream 
assignment may be achieved, for example, by assigning a particular value to the program 
identifier (PTD) for stream 656. If the requested IPG page is already being broadcast as 

25 shown in Figs. 2A and 2B, then stream 656 needs not be assigned. 

In a third step 606, the requested IPG page is pointcast to first terminal 652 
via assigned stream 656. This may be achieved by transmitting packets that are identified 
by the particular PID value and contain a video sequence of the requested IPG page. The 
pointcast needs only to be received by first terminal 652 and does not need to be received 

30 by other terminals. The pointcast is sent downstream from head-end 102 or local 

neighborhood equipment 104 to first terminal 652. If the requested IPG page is already 
being broadcast as shown in Figs. 2A and 2B, then the pointcast needs not be performed. 
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In a fourth step 608, a request for an IPG page is received from a second 
terminal 654. In this example, the IPG page requested by second terminal 654 is the same 
as the IPG page requested by first terminal 652. Similar to the first request, the second 
request is transmitted upstream from second terminal 654 to head-end 102 or local 
5 neighborhood equipment 104 via communications network 100 via an out-of-band 
network or an in-band network. Second terminal 654 may be in the same or different 
geographic area as first terminal 652. 

hi a fifth step 610, the identifier (e.g., PID value) for the assigned stream 
656 is transmitted from head-end 102 or local neighborhood equipment 104 to second 

10 terminal 654. This enables the next step 612 to occur without use of additional PIDs or 
additional network bandwidth. 

And in a sixth step 612, second terminal 654 receives the requested IPG 
page via the same assigned stream 656, which was used to deliver the IPG page to first 
terminal 652. Second terminal 654 may be set to decode and present packets that are 

15 identified by the particular PID value for stream 656. Such packets contain the video 
sequence of the requested IPG page. In this manner, "sharing" of stream 656 occurs, 
changing the previous "single" pointcast to a "double" pointcast. 

Similarly, other terminals may "share" the pointcast if they request the 
same IPG page and can receive the requested IPG page via the same stream 656. In this 

20 manner, any number of terminals may share the pointcast. This sharing results in more 
efficient use of the available bandwidth. 

FIG. 6B depicts a third pull topology 650 for demand-casting IPG pages in 
accordance with an embodiment of the invention. Topology 650 corresponds to pointcast 
"sharing" method 600 shown in FIG. 6A. As shown in FIG. 6B, a request is transmitted 

25 upstream from first terminal 652 to head-end 102 or local neighborhood equipment 104 
via communications network 100. In response, the requested IPG page is pointcast by 
stream 656 from head-end 102 or local neighborhood equipment 104 to first terminal 652. 
Next, a second request for the same IPG page is transmitted upstream from second 
terminal 654 to head-end 102 or local neighborhood equipment 104 via communications 

30 network 100. In response, the identifier for stream 656 is transmitted from head-end 102 
or local neighborhood equipment 104 to second terminal 654. Subsequently, second 
terminal 654 uses the identifier to receive the IPG page from the same stream 656. 
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FIG. 6C is a flow diagram showing a method 660 for terminating (or 
continuing) demand-casts in accordance with third pull method 600. As described below, 
method 660 includes five steps. 

In a first step 662, a terminal finishes viewing a stream used to send an 
5 IPG page, hi the example described above in Figs. 6A and 6B, the terminal may be either 
first terminal 652 or second terminal 654. hi general, the terminal may be any of the 
terminals that are sharing the same stream, or the last terminal to view a stream that was 
previously shared. 

hi a second step 664, head-end 102 or local neighborhood equipment 104 
10 is notified that the terminal has finished viewing the stream. Such notification can be 
achieved by the terminal by sending a communication upstream to head-end 102 or local 
neighborhood equipment 104 via an out-of-band or in-band network. 

In a third step 666, a determination is made whether or not that stream is 
being viewed by one or more terminals. As described in more detail below, this 
1 5 determination is done within head-end 102 or local neighborhood equipment 104 and may 
be done by a bandwidth manager in conjunction with a session manager. 

hi a fourth step 668, if one or more terminals are still viewing that stream, 
then head-end 102 or local neighborhood equipment 104 continues to transmit the stream. 
Such transmission is typically performed by an in-band delivery system. 
20 Finally, in a fifth step 670, if no other terminals are viewing that stream, 

then the stream is "torn down" so that it is no longer transmitted and no longer takes up 
network bandwidth. The torn-down stream is then available for reassignment and the 
bandwidth can be reused to transmit a different pointcast, narrowcast, or broadcast. 

25 C. DEMAND-CAST SYSTEM 

1. Guide Page Usage Frequency Distribution 

The usage of guide pages can be characterized by their frequency 
distribution. Certain pages in a guide page matrix, such as those in the current time slot 
30 and adjacent time slots ("near look-ahead") are likely to be accessed more frequently by 
viewers. Other guide pages, such as the "far look-ahead" pages, are likely to be accessed 
less frequently. These characteristics of guide page usage can be supported by a demand- 
cast model described herein. Access to all possible guide pages in the guide page matrix 
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can be achieved by sending in a transport stream a combination of continually broadcast 
guide pages for pages that are more frequently accessed, and temporarily broadcast or 
demand-cast guide pages for pages less frequently accessed. In an embodiment, current 
and near look-ahead pages are sent in a broadcast fashion and far look-ahead pages are 
5 sent in a demand-cast fashion. 

2. Demand-cast Overview 

A demand-cast IPG system is a two-way system employing 
communication between the terminal in the communications network and the head-end 

10 via a back-channel. Demand-cast pages are inserted in the transport stream for temporary 
broadcast in response to access demand generated by viewers in the network. When a 
particular viewer requests a particular guide page, one of two things can occur. If the 
requested page is already in the IPG broadcast, the terminal simply acquires the 
corresponding stream. Otherwise, if the page is not in the broadcast, the terminal requests 

1 5 the head-end to insert a stream in the IPG multiplex for the requested page. The head-end 
can then replace the least frequently accessed and not currently accessed stream in the 
IPG multiplex with a stream for the newly requested page. 

When a terminal no longer accesses a guide page, it informs the head-end 
that it has released it. When accessing a demand-cast page, an IPG application at the 

20 terminal can "time-out" following a certain period of inactivity (e.g., 2 minutes) by the 
viewer. If a time-out occurs, the terminal can inform the head-end that it has released the 
page. Informing the head-end when demand-cast pages are released ensures that non- 
accessed demand-cast pages are available for substitution. If a terminal requests a new 
demand-cast page to be inserted into the IPG multiplex and there is no slot available in 

25 the IPG multiplex, the head-end refuses to insert a stream for the newly requested guide 
page, which then results in a blockage. Most statistical multiplexed systems are 
susceptible to blockage if loaded with an excessive number of users and during chaotic 
episodes. An advantage of the demand-cast model is that if a particular page is likely to 
be extensively accessed, such as a page listing a major sports event, the page only needs 

30 to be inserted once into the transport stream. The page is then readily accessible by any 
number of terminals without consuming additional bandwidth. 
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3. Latency in Broadcast vs. Demand-cast 

Access to guide pages within a short delay (i.e., with low latency) is an 
important feature for interactive program guide. Continually broadcast pages offer a low 
latency access, whereas demand-cast pages may incur additional processing delays if not 
5 yet included in the transport stream. In an embodiment, frequently accessed pages, such 
as those in the current time slot and near look-ahead time slots, and perhaps prime-time 
slots, are broadcast continually so that they can be accessed with the lowest possible 
latency. Less frequently accessed far look-ahead pages can be sent via demand-cast. 



4. System Description 

FIG. 7 is a diagram of a two-way system 700 that can efficiently deliver 
demand-cast video sequences in accordance with an embodiment of the invention. 
System 700 includes a session manager (SM) 702 and a transport stream generator (TSG) 
704. 

Session manager 702 and transport stream generator 704 maybe co- 
located within a distribution center. The distribution center may comprise, for example, 
head-end 102 in communications network 100. Alternatively, session manager 702 and 
transport stream generator 704 may be at different locations. For example, session 
manager 702 may be located at head-end 102, and transport stream generator 704 may be 
located at local neighborhood equipment 104 in communications system 100. 

Session manager 702 and transport stream generator 704 are both coupled 
to a number of terminals 708 via a distribution network. The distribution network may 
comprise, for example, a cable distribution network as illustrated in FIG. 1. In that 
example, terminals 708 would comprise terminals 108 or an equivalent functionality 
integrated into a computer system or advanced television. Alternatively, for example, the 
distribution network may comprise a satellite communications system or another type of 
communications system (telephonic, wireless, etc.). 

One terminal 708 and its links to session manager 702 and transport stream 
generator 704 are illustrated in FIG. 7. In the specific embodiment shown in FIG. 7, 
terminal 708 receives in-band communication from transport stream generator 704 and 
sends out-of-band (OOB) communications to session manager 702. In an alternative 
embodiment, the communication to session manager 702 may comprise upstream in-band 
communications. 
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Session manager 702 may comprise, in one embodiment, a computer 
system residing at head-end 102. The computer system may comprise, for example, a 
computer server running a particular operating system (e.g., a version of the UNIX or 
Windows operating system). The computer system may receive out-of-band 
5 communication from terminals 708 via a connection to the network controller. For 
example, the connection may comprise an Ethernet connection, and the network 
controller may comprise a controller from General Instruments Corp (now part of 
Motorola Inc.) or another supplier. The computer system also communicates with and 
controls transport stream generator 704 via a network connection such as an Ethernet 
10 connection. 

Session manager 702 manages delivery of IPG pages to terminals 708 on a 
number of cable nodes, with each node being served by a separate IPG multiplexed 
transport stream generated at a corresponding transport stream generator 704. Session 
manager 702 also monitors demand-cast stream usage by terminals 708. Session manager 

1 5 702 tracks IPG demand-cast streams that are acquired by at least one terminal 708. For 
example, session manager 702 can maintain a table that dynamically lists which terminals 
708 are using each stream. This tracking is performed for each IPG multiplexed transport 
stream managed by session manager 702. 

Session manager 702 also accepts messages from terminals 708 indicating 

20 that they have acquired, released, or requested demand-cast streams. A new terminal 708 
that has acquired a demand-cast stream is registered (i.e., added) to the stream, and a 
terminal 708 that has released a demand-cast stream is removed from the registry for the 
stream. Session manager 702 informs the corresponding transport stream generator 704 if 
there is no longer any terminals 708 registered to a particular demand-cast stream, and 

25 also informs transport stream generator 704 when a terminal 708 requests a demand-cast 
stream. In one embodiment, session manager 702 may time-out acquisition of a stream 
by any terminal 708 if the terminal has not released the stream within a particular period 
of time (e.g., a few minutes). The time-out may be implemented by removing terminals 
708 from the registry for the stream after the particular period of time. 

30 Transport stream generator 704 may comprise, in one embodiment, a 

computer system residing at head-end 102. The computer system may comprise, for 
example, a computer server running a particular operating system (e.g., a version of 
Windows or UNIX operating system). Alternatively, transport stream generator 704 may 
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be located apart from session manager 702, for example, at local neighborhood equipment 
104. Each transport stream generator 704 is coupled to an associated session manager 
702, for example, via an Ethernet network. Transport stream generator 704 may generate 
one or more IPG multiplexed transport streams, with each transport stream being 
broadcast to a respective node in the distribution system. 

In one embodiment, the IPG multiplexed transport stream comprises an 
MPEG transport stream, hi this case, transport stream generator 704 may communicate 
with terminals 708 via tables in the private section of the MPEG transport stream. Such 
table may include a list of available demand-cast streams, along with the address of the 
source transport stream generator 704 and information to identify the particular IPG 
multiplexed transport stream to which the table belongs. 

Transport stream generator 704 manages each IPG multiplexed transport 
stream that it generates. Transport stream generator 704 receives information from 
session manager 702 indicating whether each demand-cast stream being served is 
currently being acquired by any terminal, or not at all. That is, transport stream generator 
704 is informed by session manager 702 when a demand-cast stream is no longer being 
acquired by any terminals 708. 

In one embodiment, transport stream generator 704 maintains a status for 
each demand-cast stream being served. The status for each stream is adjusted upon 
receipt by transport stream generator 704 of certain messages from session manager 702. 
hi an embodiment, the basic states for the stream status comprise an "acquired" state that 
denotes that the demand-cast stream is being acquired by one or more terminals 708, and 
a "released" state that denotes that the demand-cast stream is not being acquired by any 
terminal 708. Transport stream generator 704 continues to serve "acquired" demand-cast 
streams by multiplexing them into the appropriate transport streams and replaces 
"released" demand-cast streams with new demand-cast streams upon receipt of request 
messages from session manager 702. In an embodiment, transport stream generator 704 
also keeps track of the order in which the streams are released, so that the oldest released 
stream may be used as the most likely candidate for replacement. 

If all demand-cast streams in a particular IPG multiplexed transport stream 
are "acquired," then a new stream may not be inserted into the transport stream, and 
transport stream generator 704 may refuse any new requests. In such case, a message 
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indicating such refusal may be sent to session manager 702 and/or the requesting terminal 
708. 

In an embodiment, terminal 708 comprises a set-top terminal (STT) for use 
by a service subscriber. The STT may comprise an embedded system that includes a 
5 tuner, a demultiplexer, and a decoder, as described in further detail below. The STT 
drives the subscriber's display unit or TV set, and it may be coupled to transport stream 
generator 704 via an RF feed from a cable distribution network. The IPG pages may be 
received from a particular IPG multiplexed transport stream on a particular modulated 
carrier signal, hi an embodiment, the IPG multiplexed transport stream may comprise an 

1 0 ensemble of elementary MPEG video streams, with each elementary stream representing 
a portion of the guide. 

In an embodiment, terminal 708 includes IPG client software application 
that resides at the terminal. The IPG client application is responsible for presenting the 
IPG to the viewer, and demultiplexes and decodes IPG pages requested by the user. If a 

15 requested page is already being received via the IPG multiplexed transport stream, then 
the IPG client application acquires the stream immediately and sends a message to 
session manager 702 indicating that it has acquired the stream. And if the requested page 
is not in the IPG multiplexed transport stream, then the IPG client application sends a 
request message to session manager 702. Subsequently, the IPG client application 

20 acquires the stream once it is transmitted by transport stream generator 704 and received 
by terminal 708. hi addition, if a stream is no longer being acquired, the IPG client 
application sends a release message to session manager 702. In an embodiment, if there 
is no remote control or other activity by the user for a particular period of time (e.g., a 
few minutes), then the IPG client application times-out the acquisition. The time-out may 

25 be accomplished, for example, by sending a release message to session manager 702 and 
acquiring a broadcast stream instead. 

D. MAJOR MODULES OF DEMAND-CAST SYSTEM 

The demand-cast system includes three major subsystems: the set top 
30 terminal (STT), the session manager (SM), and the transport stream generator (TSG). For 
a better understanding of the invention, a specific implementation of each subsystem is 
now described. Other implementations are also possible and within the scope of the 
invention. 
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1. Set-Top Terminal (STT) 

The STT is the end-user or cable service subscriber 
tuner/demultiplexer/decoder and embedded system. In an embodiment, the STT used in 
5 initial pilot deployments of the demand-cast system is the General Instruments DCT- 
2000. The STT is coupled to the cable operator RF feed and drives the subscriber's 
display unit or TV set. The IPG content is provided in an IPG transport stream (i.e., IPG 
multiplex) located on a specific QAM carrier. The IPG multiplex contains an ensemble 
of elementary MPEG video streams, with each elementary video stream representing 

10 portions of the guide and some of these streams representing guide grid pages. The STT 
receives messages from the head-end via tables in the private section of the IPG transport 
stream (in-band messaging.) The STT sends messages to the head-end via an out-of-band 
back-channel or return path. 

The STT includes an IPG application that is responsible for presenting 

15 (e.g., the DIVA Interactive Program Guide) to the viewer. The IPG application 

demultiplexes and decodes IPG pages requested by the user. If a particular page is in the 
IPG transport stream, the STT can quickly acquire the stream and inform the session 
manager that it has requested the page. And if the page is not in the IPG multiplex, the 
STT also sends a message to the session manager that it has requested it. The STT then 

20 acquires the stream once the stream is included in the JPG multiplex. When the STT no 
longer acquires a particular guide stream, it informs the session manager that it has 
released the stream. 

In an embodiment, if the STT is on a particular demand-cast stream for 
more than a particular period of time (e.g., 2 minutes) without any remote control activity, 

25 the STT times-out. The STT then acquires a broadcast stream instead and informs the 
session manager that it has released the demand-cast stream. 

2. Session Manager (SM) 

In an embodiment, the session manager is implemented with a computer 
30 system (e.g., a SPARC Station running the Solaris operating system from 

SunMicrosystems, Inc.) residing at the cable head-end. The session manager is coupled 
via Ethernet to the server side of a network controller (NC) from General Instruments 
Corp. and is the receiver of out-of-band return path messages originating from the STTs. 
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The session manager can handle STTs on multiple cable nodes, each node being served 
by a separate IPG multiplex. The session manager communicates with and controls the 
transport stream generators via Ethernet. The transport stream generators generate the 
IPG transport streams. 

5 The session manager manages one or more cable networks and monitors 

demand-cast stream usage. The session manager also tracks IPG demand-cast streams 
that are acquired by at least one STT and maintains a dynamic list of STTs that are using 
each demand-cast stream. This tracking is achieved for each IPG multiplex managed by 
the session manager. The session manager accepts messages from the STTs indicating 

10 requests for, or release of, demand-cast streams. An STT that has acquired a demand-cast 
stream is registered to the stream, and an STT that has released a demand-cast stream is 
removed from the stream's registry. The session manager informs the transport stream 
generator if there are no longer any STTs using a particular demand-cast stream, and also 
informs the transport stream generator when an STT requests a demand-cast stream. 

15 In an embodiment, the session manager times-out an STT from a demand- 

cast stream if the STT has not released the stream within a particular time period (e.g., a 
few minutes). The session manager can achieve this by removing the STT from the 
demand-cast stream's registry. 

20 3. Transport Stream Generator (TSG) 

In an embodiment, the transport stream generator is implemented with a 
computer system (e.g., running a WindowNT operating system from Microsoft Corp.) 
residing at the cable head-end. The transport stream generator is coupled via Ethernet to 
the session manager controlling it. The transport stream generator produces one or more 

25 IPG transport streams, with each transport stream being broadcast to a respective node. 
In an embodiment, the transport stream generator communicates with the STTs via tables 
in the private section of the IPG transport streams. The table contains a list of the 
available demand-cast streams along with the IP address of the source transport stream 
generator (e.g., its IP address) and the channel number of the IPG multiplex (i.e., which 

30 multiplex it is in the transport stream generator). 

The transport stream generator manages the transport stream for each IPG 
multiplex it generates. The transport stream generator receives information from the 
session manager for each demand-cast stream indicating whether the stream is currently 
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acquired by any STT or released by all STTs. The transport stream generator is informed 
by the session manager when there is no longer any STT on a particular demand-cast 
stream and when an STT requests a demand-cast stream. 

The transport stream generator maintains the status for all demand-cast 
5 streams in each IPG multiplex. The transport stream generator adjusts the status for each 
demand-cast stream each time it receives a message from the session manager for the 
stream. The basic status for each stream includes "acquired" for a stream that is in use by 
one or more STTs and "released" for a stream that is not in use by any STT. The 
transport stream generator continues to send "acquired" streams in its IPG multiplexes 
1 0 and replaces "released" streams with new demand-cast streams as they are requested. 

The transport stream generator also keeps track of the age of the released streams and the 
best candidate for replacement is the oldest released stream. If all demand-cast streams in 
a multiplex are "acquired" then it may not be possible to insert a new stream when 
requested and the transport stream generator can refuse to process the request. 

15 

E. EXAMPLE OF INTERACTIVE PROGRAM GUIDE 

An embodiment of an interactive program guide in accordance with the 
invention is described below. The embodiment is described for purposes of illustration 
and is not meant to limit the scope of the invention. 

20 FIG. 8 depicts an example of a set of IPG pages for continual broadcast 

and other IPG pages for variable demand-cast in accordance with an embodiment of the 
invention, hi the specific example shown in FIG. 8, 40 IPG pages are continually 
broadcast and up to 30 IPG pages may be variably demand-cast. There are 10 guide 
pages per time slot, and the continual broadcast includes 10 guide pages for the current 

25 time slot and 30 guide pages for the next three 1-hour time slots. The variably demand- 
cast pages may be any pages within the guide page matrix that are not currently being 
broadcast. 

In such a system, when a request for a guide page is made by a particular 
terminal, either one of two scenarios can occur. First, if the page is already in the IPG 
30 broadcast, then the terminal simply acquires the stream for the page from the IPG 

broadcast. Alternatively, if the page is not in the broadcast, then the terminal transmits a 
request for the page to the head-end. The head-end may then fulfill the request by 
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replacing the currently transmitted stream that is least frequently accessed and not 
currently accessed with another stream containing the requested page. 

Subsequently, the terminal eventually ends its access to the guide page. 
This may occur because the user has instructed the terminal to view a different page. 
5 Alternatively, this may occur because of a time-out due to inactivity over a particular 
period of time (e.g., 2 minutes), hi any case, if the terminal is no longer accessing the 
guide page, then the terminal transmits a message to the head-end indicating that it has 
released the corresponding stream. Informing the head-end when demand-cast pages 
become released ensures that non-accessed demand-cast pages become available for 

10 substitution, as described above. 

An advantage of the invention is that, if a particular page is extensively 
accessed (such as a page listing a major sports event), then the system needs to insert the 
particular page only once into the transport stream. Once inserted, the page is readily 
accessible by any number of terminals without requiring additional bandwidth. Other 

15 systems may be more susceptible to blockage, which occurs, for example, when a newly 
requested page cannot be inserted into the transport stream because no bandwidth is 
available within the transport stream. 

An IPG delivery system in accordance with an embodiment of the 
invention is a two-way system that is capable of supporting two-way communication 

20 between the terminals on the cable network and the equipment in the cable head-end. For 
example, communication may be transmitted from the terminals to the head-end via a 
back-channel, and content may be transmitted from the head-end to the terminals by 
insertion into a transport stream. 

FIG. 9 depicts an example of an IPG page 900 in accordance with an 

25 embodiment of the invention. In the specific embodiment shown in FIG. 9, IPG page 900 
includes a time slot region 905, a guide region 910, a video region 920, an icon region 
940, a program description region 950, a logo region 960, and a date/time display 970. 
Other designs for the IPG page with different layouts, configurations, and combinations 
of regions and objects can be contemplated and are within the scope of the invention. 

30 Time slot region 905 includes a first time slot object 905a and a second 

time slot object 905b that indicate the time slots for which program guide is being 
provided on the IPG page. Guide region 910 is used to display program listings for a 
group of channels, hi the embodiment shown in FIG. 9, the program listings show the 
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available programming in two half-hour time slots. Guide region 910 thus includes a 
number of channel objects 912a through 912j used to display channel information for a 
guide listing of channels. Guide region 910 further includes a pair of channel indicator 
icons 914a and 914b that identifies the current cursor location. 

5 Program description region 950 is used to present descriptive information 

relating to a particular program selected from the program listings, or may be used to 
show other information. Video region 920 maybe used to display images, videos, text, or 
a combination thereof, which may be used for advertisements, previews, or other 
purposes. Video region 920 maybe implemented as described above in a server-centric 

10 manner. Logo region 960 may include a logo of a service operator or other entity and 
may be optionally displayed. Date/time display 970 may be configurable by the user and 
may also be optionally displayed. 

Icon region 940 is used to display various icons, which may be created 
and/or enabled by the user. Each icon in icon region 940 can represent a filter or a link to 

1 5 another IPG page or a particular interface. Each filter selects a particular type of 

programming to be included in the program listings shown in guide region 910. For 
example, a Pay Per View (PPV) icon 941 may be a filter that selects only PPV 
programming to be included in the program listings. A Favorites icon 942 may be a filter 
that selects only channels designated by the user to be among his or her favorites. A 

20 Movies icon 943 may be a filter that selects only movies or movie channels. A Kids icon 
944 may be a filter that selects only channels for children or programming appropriate for 
or produced for viewing by children. A Sports icon 945 may be a filter that selects only 
sports channels or sports-related programming. A Music icon 946 is a link to a music 
interface. An Options icon 947 may also be a link to a menu of IPG options that the user 

25 may select amongst. The options may include (1) configuration and selection/deselection 
information of IPG related services, (2) custom information such as deactivating some of 
the filters or accessing the custom condensed listing menus, and others. A Weather icon 
948 may be a link to an interface to weather information. 

As an illustration, in a system comprising 80 channels of information, the 

30 channels are displayed in 1 0-channel groups having associated with them two half-hour 
time slots. In this organization, 8 video PIDs are provided to carry the present-time 
channel/time/title information, one or more audio PIDs are provided to carry the audio 
barker and/or one or more data PIDs (or other data transport method) are provided to 
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carry the program description data, overlay data, and the like. To fully broadcast 
interactive program information for up to 24 hours in advance, 192 (e.g., 8*24) video 
PIDs are provided, along with one or more audio PIDs and, optionally, one or more data 
PIDs. 

5 The time depth of a program guide, which is defined by the amount of 

time in programming, is provided in the broadcast video PIDs for the particular channel 
groups. The channel depth of the program guide is defined by the number of channels 
available through the guide (as compared to the total number of channels in the system). 
In a system providing only half of the available channels via the broadcast video PIDs, 

10 the channel depth is 50%. In a system providing 12 hours of "look-ahead" time slot, the 
time depth is 12 hours. In a system providing 16 hours of "look-ahead" time slot and 4 
hours of "look-back" time slot, the time depth is +16/-4 hours. 

The video streams representing the IPG are sent in a one or more transport 
streams, within the form of a single program or multi-programs as described above. A 

15 user desiring to view the next 1-hour time interval (e.g., 10:00 - 1 1 :00) may activate a 
"scroll right" object (or move the joystick to the right when a program within guide 
region 910 occupies the final displayed time interval). Such activation results in a 
controller within the terminal noting that a new time interval is desired. The video stream 
desired for the new time interval is then decoded and displayed. If the corresponding 

20 video stream is within the same transport stream (i.e., a new PID), then the stream is 

simply decoded and presented. If the desired video stream is within a different transport 
stream, then that transport stream is extracted from the broadcast stream and the desired 
video stream is decoded and presented. And if the desired transport stream is within a 
different broadcast stream, then that broadcast stream is timed, the desired transport 

25 stream is extracted, and the desired video stream is decoded and presented. 

A user interaction requesting in a prior time interval or a different set of 
channels results in the retrieval and presentation of the desired video stream. If the 
desired video stream is not part of the broadcast video streams, then a pointcast session, 
for example, may be initiated as described above for Figs. 4A and 4B. For this pointcast 

30 session, the terminal sends a message to the head-end via a back channel requesting a 
particular stream. The head-end processes the request, retrieves the desired stream from 
the information server, and incorporates the stream within a transport stream as a video 
PID. Preferably, the desired stream is inserted into the transport stream currently being 
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tuned/selected by the terminal. The head-end further informs the terminal which PUD 
should be received and from which transport stream it should be demultiplexed. The 
terminal then retrieves the desired video PID. If the video PID is within a different 
transport stream, the terminal first demultiplexes that transport stream (possibly by tuning 
a different QAM stream within the forward channel). 

Typically, upon completion of the viewing of the desired stream, the 
terminal indicates to the head-end that it no longer needs the stream. In response, the 
head-end tears down the pointcast session. The terminal then returns to the broadcast 
stream from which the pointcast session was launched. However, as described above in 
Figs. 6A, 6B, and 6C, the method for "sharing" pointcasts may delay or avoid the need to 
tear down the pointcast session if another terminal is still utilizing the pointcast. hi 
addition, the above-described pointcast sharing technique more efficiently utilizes the 
network bandwidth allocated for pointcasts. 

Push demand-casts and pull demand-casts are associated with different 
delays (i.e., latencies). Access to IPG pages with low latency is a desirable feature in 
interactive program guide. A system that only pushes IPG pages may be able to offer 
access with the lowest possible latency, whereas a system that only pulls pages may incur 
significant processing delays in accessing each page. 

In accordance with an embodiment of the invention, more frequently 
accessed IPG pages such as those in the current time slot and near look-ahead time slots, 
and perhaps prime-time slots, are push demand-cast continually so that access can be 
achieved with low latency. Less frequently accessed (e.g., far look-ahead) pages are pull 
demand-cast. 

F. EXAMPLE OF IMPLEMENT ATIONAL ARCHITECTURES 

Four architectures for delivery of interactive program guide are described 
below. These architectures are illustrative of the architectures that may be used to 
implement various aspects of the invention. However, other architectures may also be 
used and are within the scope of the invention. 

FIG. 10 is a diagram of a first architecture 1000 for managing delivery of 
video sequences of an interactive program guide in accordance with an embodiment of 
the invention. First architecture 1000 includes a key manager 1002, a subscription/billing 
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manager 1003, an IPG generator 1006, and a head-end 1002. First architecture 1000 is 
capable of providing encryption for the IPG content. 

Head-end 1002 couples to a number of terminals 1008 via an in-band 
network and/or an out-of-band (OOB) network. Head-end 1002 includes various 
elements that couple together and interact with each other to provide the desired 
functionality. In the embodiment shown in FIG. 10, head-end 1002 includes an 
advertising/HTML content source 1007, an IPG content source 1009, a compositor 1010, 
an encoder 1012, a processor 1014, a multiplexer (MUX) 1016, an encryptor 1018, an in- 
band delivery system 1020, a controller 1022, a session manager 1024, an access manager 
1026, a bandwidth manager 1028, and an out-of-band (OOB) equipment 1030. 

It is noted that session manager 702 in FIG. 7 encompasses the 
functionality of a number of elements in FIG. 10, including session manager 1024 and 
bandwidth manager 1028. Also, it is noted that transport stream generator 704 in FIG. 7 
also encompasses the functionality of a number of elements in FIG. 10, including 
processor 1014 and multiplexer 1016. 

FIG. 1 1 is a diagram of a second architecture 1 100 for managing delivery 
of video sequences of an interactive program guide in accordance with an embodiment of 
the invention. Second architecture 1 100 includes the elements in first architecture 1000. 
In addition, second architecture 1 100 includes local neighborhood equipment 1004 and a 
video-on-demand (VOD) server 1005. Second architecture 1 100 is also capable of 
providing encryption for the IPG content. 

As shown in FIG. 11, local neighborhood equipment 1004 couples to 
head-end 1002 via an in-band network and an out-of-band messaging system. Local 
neighborhood equipment 1004 also couples to a number of terminals 1008 via a local in- 
band network. Local neighborhood equipment 1004 includes various elements that 
couple together and interact with each other to provide the desired functionality. Local 
neighborhood equipment 1004 typically includes a subset of the type of components in 
head-end 1002. In the embodiment shown in FIG. 11, local neighborhood equipment 
1004 includes a processor 1 1 14, a multiplexer 1 1 16, an encryptor 1 1 18, a local delivery 
system 1 120, a controller 1 122, a session manager (SM) 1 124, an access manager (AM) 
1 126, and a bandwidth manager (BWM) 1 128. 

FIG. 12 is a diagram of a third architecture 1200 for managing delivery of 
video sequences of an interactive program guide in accordance with an embodiment of 
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the invention. Third architecture 1200 includes a local IPG center 1204, a head-end 1202, 
a service center 1206, and a number of terminals 1208. In addition, the system may be 
integrated with a video-on-demand (VOD) system 1210 and a corresponding VOD 
application 1238 at terminal 1208. Third architecture 1200 does not support encryption 
of the IPG content. 

Local IPG center 1204 generates guide page user interface (UT) screens 
and periodically sends the UI screens to an IPG server 1212 at head-end 1202. A 
multiple service operator (MSO)/third party IPG add-on content 1214 may be provided to 
IPG server 1212 from MSO equipment within head-end 1202. For example, the add-on 
content may include real-time advertisement video or HTML pages for electronic 
commerce. 

IPG server 1212 composes (C), encodes (E), processes (P), multiplexes 
(M), and modulates (QAM) the IPG content (guide plus add-on content) and sends it to a 
combiner 1216. Combiner 1216 combines the IPG content with broadcast TV, premium 
content (e.g., HBO), pay-per-view (PPV), and other content from a multiple service 
operator (MSO) content delivery system 1218. The combined content is then broadcast to 
terminals 1208 via an in-band distribution network 1220. 

Upon viewer tuning of terminal 1208 to an IPG channel, an IPG 
application 1222 at the terminal processes the IPG stream and provides the IPG via an 
application programming interface (API) 1224 to a "native" application 1226 running on 
the terminal. Native application 1226 decodes and presents the IPG to the viewer. 

In one embodiment, the TV program guide for a current time period (1- 
hour) is broadcast to viewers. In addition, two weeks of look-ahead TV programming 
may be delivered to viewers on demand via demand-cast. Upon a viewer action of 
moving a cursor to a look-ahead time interval, the terminal sends a request via a back- 
channel to a session manager (SM) 1228 (e.g., via an out-of-band channel to a reverse 
path demodulator (RPD), then to a network controller (NC), then to session manager 
1228). Session manager 1228 then causes IPG server 1212 to multiplex the requested 
IPG page into the IPG stream. 

Session manager 1228 also interacts with a subscriber/billing interface 
1230 in VOD system 1210 to coordinate access to VOD services from a link in the IPG 
user interface. The user interface also provides for access to premium content and pay- 
per-view purchasing by interaction through a two-way interface to an MSO customer 
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management system (CMS) 1232 and digital access controller (DAC) 1234 in service 
center 1206. DAC 1234 generates digital encryption-related keys. 

Third architecture 1200 also includes a bandwidth manager (BWM) 1236. 
As described above, bandwidth manager 1236 provides techniques to more efficiently 
5 utilize the limited bandwidth available for distribution of the IPG. 

It can be noted that session manager 702 of FIG. 7 encompasses the 
functionality of a number of elements in FIG. 12, including session manager 1228 and 
bandwidth manager 1236. It can also be noted that transport stream generator 704 in FIG. 
7 encompasses the functionality of a number of elements in FIG. 12, including the 
1 0 processor (P) and the multiplexer (M). 

FIG. 13 is a diagram of a fourth architecture 1300 for managing delivery 
of video sequences of an interactive program guide in accordance with an embodiment of 
the invention. Fourth architecture 1300 in FIG. 13 is similar to third architecture 1200 in 
FIG. 12 and also does not support encryption of the IPG content. 
1 5 Fourth architecture 1 300 differs from third architecture 1200 primarily in 

that some of the elements are distributed from head-end 1202 to a number of hubs 1304 in 
the distribution system. In particular, combiner 1216, processor (P), multiplexer (M), and 
modulator (QAM) are moved from head-end 1202 to each hub 1304. Thus, the 
functionality of transport stream generator 704 is transferred to hubs 1304. 

20 

G. SET TOP TERMINAL 

FIG. 14 depicts a block diagram of an embodiment of set top terminal 
(STT) 1408 suitable for producing an IPG page and supporting various aspects of the 
invention. STT 1408 includes a tuner 1412, a demodulator 1414, a transport 

25 demultiplexer 1418, an audio decoder 1420, a video decoder 1430, an on-screen display 
(OSD) processor 1432, a video compositor 1434, a frame store memory 1436, a controller 
1450, and a modulator 1470. User interaction is provided via a remote control unit 1480. 
Tuner 1412 receives, e.g., a radio frequency (RF) signal comprising, for example, a 
number of broadcast (e.g., QAM) signals from a downstream (forward) channel. Tuner 

30 1412, in response to a control signal TUNE, tunes to and processes a particular broadcast 
signal to produce an intermediate frequency (IF) signal. Demodulator 1414 receives and 
demodulates the IF signal to produce an information stream, illustratively an MPEG 
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transport stream. The transport stream is provided to a transport stream demultiplexer 
1418. 

Demultiplexer 1418, in response to a control signal TD produced by 
controller 1450, demultiplexes (i.e., extracts) an audio stream A and a video stream V. 
The audio stream A is provided to audio decoder 1420, which decodes the audio stream 
and provides a decoded audio stream to an audio processor (not shown) for subsequent 
presentation. The video stream V is provided to video decoder 1430, which decodes the 
compressed video stream V to produce an uncompressed video stream VD that is 
provided to video compositor 1434. OSD processor 1432, in response to a control signal 
OSD produced by controller 1450, produces a graphical overlay signal VOSD that is 
provided to video compositor 1434. In an embodiment, during transitions between 
streams representing different IPG pages, the buffers in the decoder are not reset. As 
such, the pages seamlessly transition from one page to another. 

Video compositor 1434 merges the graphical overlay signal VOSD and the 
uncompressed video stream VD to produce a modified video stream (i.e., the underlying 
video images with the graphical overlay) that is provided to frame store unit 1436. Frame 
store unit 1436 stores the modified video stream on a frame-by- frame basis according to 
the frame rate of the video stream. Frame store unit 1436 provides the stored video 
frames to a video processor (not shown) for subsequent processing and presentation on a 
display device. 

Controller 1450 includes an input/output module 1452, a microprocessor 
1454, support circuitry 1456, an infrared (IR) receiver 1458, and a memory 1460. 
Input/output module 1452 forms an interface between controller 1450 and tuner 1412, 
transport demultiplexer 1418, OSD processor 1432, back-channel modulator 1470, and 
remote control unit 1480. Microprocessor 1454 cooperates with support circuitry 1456 
such as power supplies, clock circuits, cache memory, and the like as well as circuits that 
assist in executing the software routines that are stored in memory 1460. 

Although controller 1450 is depicted as a general-purpose processor that is 
programmed to perform specific interactive program guide control function in accordance 
with the invention, the controller can be implemented in hardware as an application 
specific integrated circuit (ASIC). As such, the process steps described herein are 
intended to be broadly interpreted as being equivalently performed by software, 
hardware, or a combination thereof. 
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In the embodiment shown in FIG. 14, remote control unit 1480 includes an 
8-position joystick, a numeric pad, a "Select" key, a "Freeze" key and a "Return" key. 
User manipulations of the joystick or keys of the remote control device are transmitted to 
controller 1450 via an infrared (TR) link or an RF link. Controller 1450 is responsive to 
5 such user manipulations, executes related user interaction routines 1462, and uses 
particular overlays that are available in an overlay storage 1466. 

After the signal is tuned and demodulated, the video streams are 
recombined via a stream processing routine 1468 to form the video sequences that were 
originally compressed. Stream processing routine 1468 employs a variety of methods to 

10 recombine slice-based streams, including using PID filter 1416 and demultiplexer 1418. 
Note that the PID filter implemented illustratively as part of demodulator 1414 is utilized 
to filter the undesired PIDs and retrieve the desired PIDs from the transport stream. The 
packets to be extracted and decoded to form a particular IPG page are identified by a PID 
mapping table 1464. After stream processing routine 1468 has processed the streams into 

1 5 the correct order (assuming the correct order was not produced in the LNE), the slices are 
sent to (MPEG) video decoder 1430 to generate the original uncompressed IPG pages. 

If a transport stream with two PIDs as described above is to be received 
and processed (e.g., for slice-based decoding), stream processing unit 1468 recombines 
the intra-coded slices with their corresponding predictive-coded slices in the appropriate 

20 order before the recombined streams are coupled to video decoder 1430. This process 
can be implemented by software or hardware, or a combination thereof. In the slice 
structure, only one slice is assigned per row and each row is divided into two portions 
(e.g., the guide portion and the video portion). In order for the receiving terminal to 
reconstruct the original video picture, one method is to construct the first row from its two 

25 slices in the correct order by retrieving two corresponding slices from the transport 

stream, then construct the second row from its two slices, and so on. In this manner, the 
terminal processes two PIDs in the same time period. 

PID filter 1416 can be programmed to pass the desired PIDs and filter out 
the undesired PIDs. The desired PIDs are identified by controller 1450 after the viewer 

30 selects particular IPG page to review. PID mapping table 1464 is accessed by controller 
1450 to identify which PIDs are associated with the desired IPG. If PID filter 1416 is 
available in the receiver terminal, it is used to retrieve the PIDs containing slices for the 
guide and video portions. Demultiplexer 1418 then extracts packets from these PIDs and 
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provides the packets to video decoder 1430, in the order in which they arrived. If the 
STT does not have optional PTD filter 1416, then demultiplexer 1418 performs the PID 
filtering and extracting functions. Depending on the particular STT implementation, a 
corresponding method is used to recombine and decode slice-based streams. 

5 

H. FIRST MESSAGING PROTOCOL 

A specific messaging protocol for communicating between the major 
components of the system is now described in relation to FIG. 15A through 15D. Other 
messaging protocols can also be used and are within the scope of the invention. 

10 In an embodiment, the "source" transport stream generator communicates 

with a terminal via, for example, a one-way in-band channel. The communication may 
be, for example, in the form of a "demand-cast index table" within a private section of the 
IPG MPEG transport stream. 

FIG. 15 A depicts an embodiment of the content of a demand-cast index 

1 5 table. The content may include: (a) a table version number (which increments when the 
table content changes); (b) a list of available demand-cast streams; (c) an internet protocol 
(IP) address for the source transport stream generator; (d) a MUX channel number within 
the source transport stream generator, and (e) a time of day and day of week. 

In an embodiment, the terminal communicates with the session manager 

20 via, for example, a one-way out-of-band return path. The return path may be 

implemented, for example, using a user datagram protocol/internet protocol (UDP/IP) 
service to connect the terminal to a network controller (NC) at the session manager. 

FIG. 15B depicts an embodiment of the contents of a message sent from 
the terminal to the session manager. The message content as shown includes: (a) a 

25 demand-cast stream identification; (b) the terminal's identification; (c) the IP address of 
the source transport stream generator; (d) the MUX channel number within the source 
transport stream generator; and (e) the message information itself. The message 
information may indicate: (1) an acquisition of the demand-cast stream by the terminal; 
(2) a release of the demand-cast stream by the terminal; or (3) a request for the demand- 

30 cast stream by the terminal. 

In an embodiment, the session manager communicates with the source 
transport stream generator via, for example, a two-way communications channel. The 
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two-way communications channel may comprise, for example, a TCP/IP connection over 
an Ethernet network. 

FIG. 15C depicts an embodiment of the contents of a message sent from 
the session manager to the transport stream generator. The message content as shown 
includes: (a) the demand-cast stream identification; (b) the MUX channel number within 
the source transport stream generator; and (c) a particular message/command selected 
from a set of possible messages/commands. The set of messages/commands include: (1) 
demand-cast stream released (no longer acquired by any terminal); (2) demand-cast 
stream requested; and (3) a reset command. 

Messages from the session manager to the transport stream generator may 
be acknowledged by the transport stream generator. 

FIG. 15D depicts an embodiment of the contents of an acknowledgement 
message sent by the transport stream generator back to the session manager. An 
acknowledgement message as shown includes: (a) the demand-cast stream ID; (b) the 
MUX channel number; (c) the transport stream generator's IP address; and (d) the 
acknowledgement itself. The acknowledgement may acknowledge (1) release of the 
demand-cast stream; (2) request for the demand-cast stream; or (3) reset of the transport 
stream generator. 

I. STREAM STATUS AND CONVERSIONS OF STATUS 

The following relates to stream status and conversions of status in 
accordance with a specific embodiment of the invention. Other stream statuses and 
conversions of status can also be implemented and are within the scope of the invention. 

1. Stream Status Within IPG Multiplex 

The transport stream generator models bandwidth usage for each IPG 
multiplexed transport stream that it is managing. Each demand-cast stream within each 
transport stream may be either active or inactive. Active streams are currently being 
multiplexed into the transport stream, and inactive streams are not currently being 
multiplexed into the transport stream. 

FIG. 16 depicts an example showing statuses of a number of active 
demand-cast streams in an IPG multiplex within a transport stream generator. For each 
demand-cast stream, the transport stream generator assigns a status with respect to the 
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stream's intended multiplex. Demand-cast stream statuses, in context of the transport 
stream generator, are: 

1) "Active" streams are in the IPG multiplex 

1.1) "Acquired" demand-cast streams are in the multiplex but are used by at least 
one terminal. They are referenced in the demand-cast index table in the 
private section of the IPG transport stream. They are not candidates for 
removal. 

1 .2) "Released" demand-cast streams are in the multiplex and are not used by 
any terminal. They are referenced in the demand-cast index table. They can 
become "passive". 

1.2) "Passive" demand-cast streams are also technically "released". They 
are in the multiplex but are not used by any terminal. They are not 
referenced in the demand-cast index table. They are typically a small 
fraction of the "released" demand-cast streams. A few oldest 
'released' demand-cast streams are forced to the "inactive" status by a 
maintenance thread. They are candidates for removal. 

2) "Inactive" demand-cast streams are not in the IPG multiplex. They are not 
referenced in the demand-cast index table. They may be inserted in the multiplex 

Note that the transport stream generator may remove all the "passive" 
demand-cast streams from their respective IPG multiplexes and replace them with null 
packets. It may be advantageous to leave "passive" demand-cast streams in the multiplex 
in case a terminal requests it, in which case the latency will be minimized. 



2. Conversions of Status 

25 The transport stream generator receives messages from the session 

manager. Messages received from the session manager are: 

1) "request demand-cast stream" 

2) "release demand-cast stream" The "release demand-cast stream" message includes 
the maximum number of terminals that were registered to the demand-cast stream. 

30. 3) "reset" 
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A. Transport Stream Generator Request Demand-cast Stream 
FIG. 17A illustrates the various methods for activating a demand-cast 
stream. If the transport stream generator receives a "request demand-cast stream" 
message from the serial number, then the following methods for activating the stream are 
possible. 

1) If the demand-cast stream is currently "inactive", then 

a) In a first case, if there are one or more "passive" demand-cast streams 
in the corresponding multiplex, then the transport stream generator removes a 
"passive" demand-cast stream from the multiplex, and replaces it with the new 
requested demand-cast stream. The transport stream generator adds reference to 
the new 'active' demand-cast stream in the demand-cast index table. The 
transport stream generator assigns the status 'active' to the newly inserted 
demand-cast stream. The transport stream generator acknowledges the session 
manager for the "request demand-cast stream" message by sending a "success" 
message back to the session manager. 

b) In a second case, if there are no "passive" demand-cast streams in the 
corresponding multiplex, but a 'released' demand-cast stream is included therein, 
then the transport stream generator forces the oldest 'released' demand-cast 
stream to the "inactive" status and then follows the steps described above for the 
first case. 

c) In a third case, if the transport stream generator finds no "passive" or 
"released" demand-cast stream in the corresponding multiplex, it can not fulfill 
the request. The transport stream generator acknowledges the session manager for 
the "request demand-cast stream" message by sending a "fail" message back to 
the session manager. 

2) If the demand-cast stream is currently 'released' or 'passive', then 

a) The transport stream generator changes the status of the 'released' or 
'passive' demand-cast stream to 'acquired.' The transport stream generator also 
acknowledges the session manager for the "request demand-cast stream" message 
by sending a "success" message back to the session manager. 
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B. Transport Stream Generator Release Demand-cast Stream 

If the transport stream generator receives a "release demand-cast stream" 
message from the session manager, then it acknowledges the session manager by sending 
a "success" message. If the demand-cast stream is currently 'acquired', then the transport 
5 stream generator changes the status of the stream to 'released.' 

C. Released Stream to Passive Stream Conversion 

Removal of a 'released' demand-cast stream can be done. However, such 
removal, unless necessary, may be disadvantageous. Initially, the reference to the 
'released' demand-cast stream is removed from the "demand-cast index table", then a 

10 short time later (e.g., few seconds) later the stream can be physically removed from the 
multiplex. This delay between the removal from the table and the removal from the 
multiplex prevents a race condition whereby a terminal is acquiring a demand-cast stream 
while the transport stream generator is in the process of removing it. Therefore, only 
'passive' streams are removed in accordance with an embodiment of the invention. 

1 5 The ratio of 'passive' to 'released' demand-cast stream may be specified in 

the transport stream generator configuration file. It may be maintained as a percentage 
(e.g., 10% of 'released' streams are converted to 'passive') or it can be maintained as an 
absolute number (e.g., so as to ensure that there are usually two or three 'inactive' 
demand-cast streams). 

20 FIG. 1 7B illustrates an overall process by which a released stream may be 

converted to a passive stream. Methods for determining which released streams are 
converted to passive streams include an aging method and a statistical method. In the 
aging method, the few oldest 'released' demand-cast streams are continually converted to 
'passive' status by a maintenance thread. In the statistical method, the "release demand- 

25 cast stream" messages include statistical data regarding the demand-cast stream. This 
data may provide the maximum number of terminals that were on a released stream 
before it was released. The transport stream generator converts demand-cast streams that 
have had the least amount of users to 'passive' status. 

30 J. OTHER TECHNICAL ASPECTS 

The following are further technical aspects in accordance with a specific 
embodiment of the invention. Other variations are also possible and within the scope of 
the invention. 
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1. Initial Conditions 

Set Top Terminal : When the STT launches the IPG application, it tunes to the 
QAM carrying the IPG transport stream. When the STT requests its first demand-cast 
stream, it opens the IPG channel with the session manager. When the QAM is tuned, the 
5 STT acquires the demand-cast index table and sends an "Init" command to the session 
manager. 

Session Manager : Initially, the session manager has no knowledge of the IPG 
multiplex fed to its client STTs. Upon receiving a first "request demand-cast stream" 
message from a STT, the session manager verifies that it is aware of the MUX ID. MUX 

10 ID includes the transport stream processor IP address and MUX channel within the 

transport stream generator. If the session manager is aware, then nothing happens. And 
if the session manager is not aware, the transport stream generator opens a 
communication socket with the source transport stream generator. The session manager 
maintains a log where it registers all MUXes that it controls. For each MUX in the log, 

15 the transport stream generator's IP address and MUX channel number is recorded. 

Transport Stream Generator : Initially, the transport stream generator is 
configured through its own configuration file. Configuration includes the number of 
demand-cast streams that can be supported by each IPG multiplex. The absolute number 
of 'passive' streams or the ratio of 'passive' streams to 'released' streams is specified in 

20 the configuration file 

2. Reset 

Set Top Terminal : When the STT does not "see" the PED of the demand-cast 
stream it is acquiring in the demand-cast index table, it acquires a default IPG broadcast 
PE). If the STT does not see the demand-cast index table, the STT exits the IPG 
25 application. 

Session Manager : If the session manager is down, upon reset, it looks up 
transport stream generator log file and sends a reset command to the transport stream 
generator. 

Transport Stream Generator : When the transport stream generator receives a 
30 "Reset" command from the session manager, it removes reference to all demand-cast 

streams in the demand-cast index table in the multiplex referenced by the MUX ED in the 
reset command. Then a short time (e.g., a few second) later, the transport stream 
generator removes all the demand-cast streams within the multiplex. 
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3. Scalability 

Set Top Terminal : STT messages regarding demand-cast streams include 
demand-cast stream ID, transport stream generator's IP address, and the MUX channel 
number on the transport stream generator. 

Session Manager : The session manager can manage more than one transport 
stream generator. Each IPG multiplex is referred to by the IPG address of the host 
transport stream generator and the MUX channel number on the transport stream 
generator. 

Transport Stream Generator : Each transport stream generator can manage 
more than one IPG multiplex. 

K. IPG MESSAGING SCHEME 

The systems shown in FIGS. 10 through 13 can be used to send interactive 
program guide (IPG) via broadcast and demand-cast. The IPG pages can be efficiently 
encoded and transmitted from the head-end by partitioning each IPG page into a number 
of regions (or portions) and separately encoding and transmitting the requested regions. 
For example, IPG page 900 shown in FIG. 9 can be partitioned into guide region 910, 
video region 920, icon region 940, and program description region 950. Each of these 
regions can then be encoded using a slice-based encoding scheme. Thereafter, the slices 
for each region can be transmitted from the head-end via a respective assigned PID. 

The partitioning of IPG page into regions, coding of the regions using a 
slice-based encoding scheme, and recombination of the regions at the terminal are 
described in detail in U.S. Patent Application Serial No. 09/466,990, entitled "STREAM 
INDEXING FOR DELIVERY OF INTERACTIVE PROGRAM GUIDE," and filed 
December 10, 1999. Other techniques for efficiently coding and decoding regions of IPG 
pages are described in U.S. Patent Application Serial No. [19880-003410], entitled 
"TEMPORAL SLICE PERSISTENCE METHOD and APPARATUS FOR DELIVERY 
OF INTERACTIVE PROGRAM GUIDE," filed October 10, 2000. These applications 
are assigned to the assignee of the invention and incorporated herein by reference. 

As noted above, many IPG pages may be available to list the programming 
for a large number of channels over an extended (e.g., two-week) time period. For 
example, 472 IPG pages may be available for 200 channels for a two-week period if each 
IPG page includes a guide listing for a group of 10 channels for a one-hour time slot. 
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Broadcasting all of these IPG pages would require a large amount of bandwidth and is 
typically not necessary. To conserve bandwidth, IPG pages for the current and near look- 
ahead time slots may be broadcast and other IPG pages may be sent via demand-cast 
whenever requested by viewers. 

For the information distribution systems described above, requests for IPG 
pages from the terminals are typically sent via an out-of-band network that typically 
supports a lower bit rate than the in-band network used to send programming and IPG. 
Thus, efficient techniques for sending demand-cast messages (i.e., requests) from the 
terminals to the head-end are highly desirable. 

An IPG page can be efficiently regenerated at a terminal by "assembling" 
the various regions that make up the page. Techniques for achieving this are described in 
the aforementioned U.S. Patent Application Serial Nos. 09/466,990 and [19880-003410]. 
One or more of these regions (e.g., the guide and video regions) maybe transmitted from 
the head-end, and one or more other regions (e.g., the icon region) may be generated at 
the terminal. Using the techniques described in Application Serial No. [19880-003410], a 
new (e.g., requested) IPG page may be constructed by just replacing one or more existing 
regions (e.g., the guide region) of the current page with the corresponding regions of the 
new page. The remaining regions (e.g., the icon and video regions) of the current page 
are not updated by the new page. 

In accordance with an aspect of the invention, only the necessary region or 
regions not currently received at the terminal or needs to be updated are requested by the 
terminal, and the head-end transmits only the requested regions. This demand-cast 
scheme can greatly reduce the amount of bandwidth required to support demand-cast. 

In a similar manner, a video or program description maybe requested by 
the terminal for the current IPG page. In this case, using the techniques described in 
Application Serial No. [19880-003410], only the requested region or regions for the IPG 
page need to be transmitted. These regions would then replace the corresponding regions 
in the current IPG page while the remaining regions are not updated. 

1. Messaging System for Demand-Cast 

An aspect of the invention provides an efficient messaging system to 
facilitate the IPG delivery scheme described above. This messaging system allows the 
terminals to specifically designate the requested item of information. 
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FIG. 18A is a diagram of an embodiment of a message format 1800 that 
can be used to send a demand-cast request. In this embodiment, message format 1800 
includes a region ID field 1802 and a body field 1804. Region ID field 1802 identifies a 
particular region of the IPG page being requested. Table 1 lists some of the regions that 
5 may be requested and their assigned values for region ID field 1802. 



Table 1 



Value 


Region Requested 


0 


Guide region 


1 


Video region 


2 


Icon region 


3 


Program description region 



Different and/or additional regions may be defined for the IPG page and are within the 
scope of the invention. For example, audio or other data associated with a particular IPG 

10 page may also be requested and appropriately identified by region ID field 1802. 

Body field 1804 includes the body of the request message. In an 
embodiment, the format for body field 1804 is dependent on the particular region 
specified in region ID field 1802. This provides a "hierarchical" message format that is 
well suited for defining "sub-regions" of a picture in an MPEG encoding system. 

1 5 Message formats for some of the regions are described below. 

FIG. 18B is a diagram of an embodiment of a message format 1810 that 
can be used to send a request for a particular guide listing for the guide region. In this 
embodiment, message format 1810 includes region ID field 1802, a subtype field 1812, a 
time slot field 1814, and a page offset field 1816. Based on the definition shown in Table 

20 1 , region ID field 1 802 includes a value of, e.g., zero ("0") to identify the request as being 
for a guide region. 

Subtype field 1812 identifies the particular type of guide being requested. 
As described above and shown in FIG. 9, a number of filters may be provided to allow a 
viewer to select a particular type of programming to be included in the guide listing 
25 displayed in the guide region. Such filters may include Pay Per View (PPV), Favorites, 
Movies, Kids, Sports, Music, and so on. Each filter may thus be used to provide a 
different type of guide listing, including "condensed" listings. 
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In an embodiment, subtype field 1812 includes a value indicative of the 
particular filter, if any, selected by the viewer at the time the demand-cast was requested. 
The terminal has knowledge of the filter currently selected by the viewer, if any, and can 
automatically fill in this field. Table 2 lists some of the filters that may be selected by the 
5 viewer and their exemplary assigned values for subtype field 1812. 



Table 2 



Value 


Filter Selected 


0 


None. Regular unfiltered IPG listing 


1 


Pay Per View (PPV) 


2 


Favorites 


3 


Movies 


4 


Kids 


5 


Sports 



As the viewer requests a particular IPG page at a particular time, the head- 
end identifies the content of the requested page. For example, if the viewer requests a pay 

10 per view page at a particular look-ahead time, and if there is a related condensed listing, 
then the head-end sends the condensed listing to the terminal. Otherwise, the head-end 
sends a regular IPG page that includes the requested pay per view listing. The same 
principle can be applied to other filters. 

Time slot field 1814 identifies the particular time slot of the guide listing 

1 5 being requested. As noted above, IPG pages may be available to list programming for an 
extended time period. If two weeks of guide listing is available and each IPG page covers 
a one-hour time slot, then 336 time slots are defined for that two-week period. Time slot 
field 1 8 14 is used to identify the specific time slot being requested. The requested time 
slot can be calculated based on a modulo (Mod) 336 operation. For example, a requested 

20 time slot of 500 can correspond to a time slot of 164. And if the current time slot is 100 
according to the Mod 336 operation, then 64 is the requested time slot with reference to 
the current time. 

For clarity, the above scheme is described in the context of guide listing 
for two-week period and one-hour time slot. Other time periods and time slot durations 
25 may also be used and are within the scope of the invention. Also, other schemes to 
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identify the particular time slot being requested can also be contemplated and are also 
within the scope of the invention. 

Page offset field 1816 identifies the particular IPG page selected from 
among a number of pages available for the selected time slot. As noted above, IPG pages 
5 may be available for guide listing for a large number of channels. If 200 channels are 
available and each IPG page covers a group of 10 channels, then 20 IPG pages may be 
available for each time slot. Page offset field 1816 is used to identify the specific page 
being requested. 

Again, the IPG page being requested can be identified using various 

10 schemes. In one scheme, the IPG pages for all available channels for a particular time 
slot are numbered consecutively from 0 through N. For example, if 200 channels are 
available and each IPG page includes guide listing for a group of 1 0 channels, page 0 may 
include the guide listing for channels 1 through 10, page 1 may include the guide listing 
for channels 1 1 through 20, and so on, and page 19 may include the guide listing for 

15 channels 191 through 200. For this scheme, the value in page offset field 1816 identifies 
the specific page in the time slot corresponding to the requested page. In another scheme, 
offset value from the current page number is referenced in the page offset field. 

In FIG. 18B, the width of each field in message format 1810 is typically 
dependent on the number of possible values that may be specified for that field. As a 

20 specific example, two bits would be sufficient to designate one of four possible regions 
for region ID field 1802, three bits would be sufficient to designate one of six possible 
filters (or no filter) for subtype field 1812, nine bits would be sufficient to designate one 
of 336 possible time slots, and five bits would be sufficient to designate one of 20 
possible IPG pages. Of course, additional bits may be provided for some or all of the 

25 fields to account for possible future expansion. Thus, any number of bits may be 
allocated to each of the fields and this is within the scope of the invention. 

FIG. 18C is a diagram of an embodiment of a message format 1820 that 
can be used to send a request for a particular video for the video region, hi this 
embodiment, message format 1820 includes region ID field 1802, subtype field 1804, and 

30 possibly additional fields. Based on the definition shown in Table 1, region ID field 1802 
includes a value of one ("1") to identify the request as being for a video. 

For an enhanced IPG, it may be desirable to present another video in the 
video region that is different from the common video. For example, if the viewer selects 
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a particular filter icon, then a video associated with that filter may be decoded and 
displayed in place of the common video. As another example, if the viewer selects a 
preview for a particular program, a video clip for that program may be requested (if it is 
not already transmitted) and presented for viewing. The video region may thus be used to 
implement a picture-in-picture feature for IPG. The particular video to be displayed in 
the video region may be selectable by the viewer or designated by the system. Message 
format 1820 can be used to request such video. 

For such picture-in-picture scenarios, subtype field 1804 can be used to 
refer to different types of video such as sport and kids-related video, which may be used 
for targeted advertising, hi another embodiment, instead of sub-type field 1804, a 
channel number maybe included in a second field to change to a video when the viewer 
changes channel. The time slot and page offset fields may not be used in such video 
requests and these fields maybe used to reference more detailed information about the 
requested video. 

In the IPG system described in the aforementioned U.S. Patent Application 
Serial No. 09/466,990, one common video (sometimes referred to as a video barker) is 
provided for all IPG pages. To regenerate a selected IPG page, the guide region for the 
selected page is retrieved and recombined with the common video region using a slice- 
based recombination method described in the aforementioned Application Serial Nos. 
09/466,990 and [19880-003410]. 

FIG. 18D is a diagram of an embodiment of a message format 1830 that 
can be used to send a request for an icon region or other regions such as, for example, 
request for stock ticker, weather information, other (e.g., restaurant) guide information, 
and other information. In such embodiments, message format 1830 includes region ID 
field 1802 and related subtypes and possibly additional fields. 

The message formats for the various regions described above in FIGS. 
18 A through 18D can be defined to have the same lengths (e.g., 32 bits), which may 
simplify the generation and processing of the messages. Alternatively, the message 
formats can be defined to have the different lengths, which may be more efficient. The 
message format for each region may be defined to include as many bits as required to 
specifically define that region. 
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L. RECORD MAINTENANCE SYSTEM FOR DEMAND-CAST 

For an MPEG transmission system, a program map table (PMT) is used to 
identify the video, audio, and data PIDs associated with each transmitted program, and a 
program association table (PAT) is used to identify the PIDs for the PMTs for the 
5 transmitted programs. However, certain set top terminal implementations of the MPEG 
systems may be limited in the usage of PMT and PAT. For example, one limitation may 
be the restriction in the number of PMTs per PAT and the number of video stream 
references in a PMT. 

In accordance with an aspect of the invention, a "roster" scheme is 

1 0 introduced for referencing video, audio, and data PIDs, with the roster operating in 

addition to the PMT of MPEG systems. In this scheme, the PMT is used to include video 
and audio PIDs that refer to a "splash" page. In one embodiment for the splash page, the 
PMT includes a video PID that refers to the guide region with no program text, an audio 
PID, and another video PID that refers to a barker video. As the viewer first turns on the 

15 set top terminal, or for any one of a number of error situations, the terminal looks at the 
content of the PMT to determine the splash page, and decodes and temporarily displays 
the splash page (e.g., for a fraction of a second). The use of a splash page is described in 
further detail in U.S. Patent Application Serial No. 09/635,508, entitled "METHOD AND 
APPARATUS FOR TRANSITIONING BETWEEN INTERACTIVE PROGRAM 

20 GUIDE (IPG) PAGES," assigned to the assignee of the invention and incorporated herein 
by reference. 

While processing the splash page, the terminal decodes the content of a 
separate data PID that includes a roster. In one embodiment, the data PID that includes 
the roster is referenced in the PMT. In another embodiment, the application running on 
25 the set top terminal is aware of this data PID by default. 

The roster, in addition to the PMT, is designed to reference the IPG 
streams efficiently so that the terminal is able to resolve the stream ID's and requests 
required streams from the head-end. Note that the roster approach to stream/sub-stream 
indexing described herein is not limited to IPG application and can be utilized in related 
30 applications in addition to the PMT. 

When a particular IPG page is selected by a viewer, the terminal can 
consult the roster to determine whether the selected IPG page is currently received at the 
terminal. If the answer is yes, the roster element for the selected IPG page can be 
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examined to determine the PEDs used to transmit various regions of the selected page 
(e.g., the guide, video, and icon regions). The terminal then processes (e.g., recombines 
and decodes) these PIDs to recover the selected IPG page, which is then presented to the 
viewer. 

5 The roster can further be used to support demand-cast. By consulting the 

roster, the terminal is able to determine whether a selected IPG page is currently received 
from the head-end. If the answer is no, the terminal can request for transmission of the 
streams related to the selected IPG page. 

FIG. 19A is a diagram of an embodiment of a roster 1900 that can be used 
1 0 to maintain track of IPG pages received at a terminal. In this embodiment, roster 1 900 
includes a number of roster elements 1902, one roster element for each received IPG 
page. 

In the specific embodiment shown in FIG. 19 A, each roster element 1902 
includes a page ED field 1912, a video PID field 1914, a data PID field 1916, and a bar 

15 PID field 1918. In this specific embodiment, roster element 1902 does not include an 
audio PID, since a common audio stream is utilized, although an audio PID may also be 
provided as described below. Different and/or additional fields may also be defined for 
roster element 1902 and are within the scope of the invention. The fields for a roster 
element for an associated IPG page are described below. 

20 Page ID field 1912 includes a description of the IPG page associated with, 

and identified by, the roster element, hi an embodiment, page ID field 1912 includes 
fields for the region ID, subtype, time slot, page offset, and so on, as described above in 
the message scheme. This page ID field (e.g., 32 bits of data) can provide information 
related to the guide portion and may have the format as depicted in FIG. 1 8B. 

25 Video PID field 1914 identifies the PID of a specific barker video, if any, 

for the associated IPG page. Depending on the employed encoding scheme, such as 
"temporal slice persistence", slice-level encoding, or picture level encoding, and so on, 
the video PID may refer to different stream content. Temporal slice persistence 
processing is described in detail in the aforementioned Application Serial No. [19880- 

30 003410] and slice-level and picture-level encoding is described in detail in the 
aforementioned U.S. Patent Application Serial No. 09/466,990. 

Data PID field 1916 identifies the PID that carries the description data for 
one or more channel programs, if any, for the associated IPG page. The data PID may 
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also be used to send any IPG user interface related data, such as stock tickers, weather 
information, and so on. 

Bar PID field 1918 identifies the PID used to send "interactivity" data for 
the IPG page and possibly other graphics overlay data that is pre-rendered at the head- 
5 end. This interactivity data may include correlation data for arranging the user interaction 
with the IPG functionality. For example, the data may include information to indicate 
which elements (e.g., which channel listings and/or icons) in the associated IPG page are 
to be masked and which other elements are to be revealed in response to certain user 
interactions. The mask or reveal feature, along with user interaction functionality of IPG 

10 pages, are described in further detail in U.S. Patent Application Serial No. 09/293,526, 
entitled "DATA STRUCTURE AND METHODS FOR PROVIDING AN 
INTERACTIVE PROGRAM GUIDE," filed April 15, 1999, and Serial No. 09/359,560, 
entitled "INTERACTIVE USER INTERFACE," filed July 22, 1999, both assigned to the 
assignee of the invention and incorporated herein by reference. 

1 5 Although each roster element 1902 defines a specific IPG page, or a 

specific (e.g., guide) region that is representative of the IPG page, a number of roster 
elements can reference and share the same video PID, data PID, and/or bar PID. 

FIG. 19B is a diagram of an embodiment of another roster 1920 that can 
be used to maintain track of IPG pages received at a terminal for multiple barker video 

20 streams in picture-in-picture applications. Roster 1920 includes a number of roster 

elements 1922, one roster element for each received IPG page. In this embodiment, each 
roster element 1922 includes page ID field 1912, video PID field 1914, an audio PID field 
1924, data PID field 1916, and bar PID field 1918. hi this embodiment, an additional 
audio PID field 1924 is referenced to specify an audio stream related to video PID 1914. 

25 Depending on the desired implementation, the audio PID may refer to different stream 
content. For example, this audio stream may be related to the video barker identified in 
video PID field 1914. As there may be multiple barker video streams, associated multiple 
different audio streams are referenced in the roster. For a common barker video, the 
audio stream does not need to be referenced since there is only one associated audio 

30 stream. 

ha an embodiment, one roster element is generated and transmitted by the 
head-end for each IPG page transmitted via broadcast or demand-cast. Since there is a 
limitation on the number of PIDs that can be utilized in MPEG systems, the complete 
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number of IPG related streams including current and look-ahead time is not referenced in 
the roster. Instead, the roster includes only the PEDs that are currently in the broadcast or 
demand-cast streams. As new IPG pages are transmitted by the head-end and/or old IPG 
pages are removed, the roster is updated. The roster is transmitted as a data stream to the 
5 set top terminals. 

In an embodiment, the terminal maintains a roster for the IPG pages 
received from the head-end. The terminal receives and processes the data stream to 
recover the roster elements. The terminal then forms the roster, which includes the 
recovered roster elements. The roster includes one roster element (i.e., record) for each 

10 IPG page broadcast or demand-cast by the head-end. 

The terminal can thereafter review the page ID of the elements in the 
roster to determine which IPG pages are received from the head-end and available. If a 
particular IPG page is selected by the viewer, the terminal can first consult the roster to 
determine whether the selected page is currently received from the head-end. If the 

15 answer is yes, the terminal can review the roster element for the selected page to 
determine the PTDs for various regions of the selected page. The terminal can then 
process these PIDs to regenerate the selected page. And if the selected page is not 
currently received, the terminal can request for transmission of the selected page. 

The roster can be advantageously used to maintain track of contents 

20 delivered by the head-end of an information distribution system. The roster has some 
advantages over the PMT and PAT defined by the MPEG standard. First, the roster 
element can be flexibly defined to include the desired information. More columns (i.e., 
fields) can be easily defined as needed. Second, there is no set limitation on the number 
of roster elements that may be included in the roster. In contrast, the number of PMTs 

25 per PAT and the number of video stream references in a PMT may be limited in certain 
MPEG-2 implementations. Third, the roster can be easily updated as new IPG pages are 
transmitted and old IPG pages are removed. The roster can be efficiently transmitted as a 
data stream and made available to the terminals. 



30 1. Other Applications for Messaging and Maintenance Systems 

The above-described messaging and roster schemes are especially suited 
for interactive program guide, which is commonly used for television and broadcast 
distribution systems. However, the messaging and roster schemes describe above can 
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also be advantageously used for other guide applications such as, for example, dining 
guide, local shopping, news, and others. In general, the above-described schemes can be 
used to request and keep track of delivery of any region (or portion) of any picture. For 
example, the techniques described above can be used to request and keep track of 
5 delivery of stock quotes, sports scores, headline news, traffic reports, other guides, and so 
on. 

The foregoing description of the preferred embodiments is provided to 
enable any person skilled in the art to make or use the invention. Various modifications 
to these embodiments will be readily apparent to those skilled in the art, and the generic 
10 principles defined herein may be applied to other embodiments without the use of the 
inventive faculty. Thus, the invention is not intended to be limited to the embodiments 
shown herein but is to be accorded the widest scope consistent with the principles and 
novel features disclosed herein. 
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WHAT IS CLAIMED IS: 



1 1 . A method for maintaining records of information related to an 

2 interactive program guide (IPG) provided via a plurality of IPG pages, the method 

3 comprising: 

4 forming a plurality of record elements, wherein each record element is 

5 associated with a respective IPG page received at a terminal and further includes 

6 a first field indicative of a specific one of the plurality of IPG pages 

7 corresponding to the associated IPG page. 

1 2. The method of claim 1 , further comprising: 

2 updating the plurality of record elements to reflect changes in IPG pages 

3 received at the terminal. 

1 3. The method of claim 2, wherein the updating includes 

2 inserting an additional record element for each new IPG page received at 

3 the terminal. 

1 4. The method of claim 2, wherein the updating includes 

2 removing an existing record element for an associated IPG page 

3 previously, but no longer, received at the terminal. 



1 5 . The method of claim 1 , wherein each IPG page includes a plurality of 

2 defined regions, and wherein the first field of each record element identifies a first packet 

3 identifier (PID) for a program listing for a guide region of the associated IPG page. 



1 6. The method of claim 5, wherein each record element further includes 

2 a second field identifying a second PID for a video stream for a 

3 video region of the associated IPG page. 

1 7. The method of claim 5, wherein each record element further includes 

2 a third field identifying a third PID for a data stream for the 

3 associated IPG page. 
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1 8. The method of claim 5, wherein each record element further includes 

2 a fourth field identifying a fourth PID for data used to indicate 

3 presentation of contents of the associated IPG page based on defined user 

4 interactions. 

1 9. The method of claim 5, wherein each record element further includes 

2 a fifth field identifying a fifth PID for an audio stream for the 

3 associated IPG page. 

1 10. The method of claim 1 , wherein the plurality of record elements are 

2 generated at a server of an information distribution system and sent to the terminal. 

1 11. The method of claim 1 0, wherein one record element is generated by 

2 the server for each IPG page transmitted therefrom as either a broadcast or a demand-cast 

3 in response to a request for the IPG page. 

1 12. The method of claim 10, wherein the plurality of record elements are 

2 sent from the server via a data stream. 

1 13. The method of claim 12, wherein the data stream used to send the 

2 record elements is assigned a particular PID that is identified in a program map table 

3 (PMT) for a transport stream that includes the data stream. 

1 1 4. A method for providing information for an interactive program guide 

2 (IPG), wherein the IPG is provided via a plurality of IPG pages, the method comprising: 

3 receiving at a server a request for a particular IPG page; 

4 assigning a packet identifier (PID) for the requested IPG page; 

5 transmitting the requested IPG page to a requesting terminal via the 

6 assigned PID; 

7 generating a record element indicative of the transmitted IPG page; and 

8 transmitting the record element to the requesting terminal. 
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2 
3 



15. The method of claim 14, wherein each IPG page includes a plurality 
of defined regions, and wherein the request is for a particular region of the particular IPG 
page. 



1 1 6. The method of claim 1 5, wherein the requested region comprises a 

2 program listing for a guide region of the IPG page. 

1 17. The method of claim 1 5, wherein the requested region comprises a 

2 video for a video region of the IPG page. 

1 1 8. In an information distribution system, a terminal operable to process 

2 information for an interactive program guide (IPG) provided via a plurality of IPG pages, 

3 the terminal comprising: 

4 a controller configured to 

5 receive a selection for a particular IPG page, 

6 determine whether the selected IPG page is currently received at 

7 the terminal, and 

8 if the selected IPG page is currently received at the terminal, 

9 identify one or more packet identifiers (PIDs) used for the selected IPG page; and 

10 a video decoder operatively coupled to the controller and configured to 

1 1 process the one or more identified PIDs to form the selected IPG page. 



1 1 9. The terminal of claim 18, wherein the controller is further configured 

2 to generate a request for the selected IPG page if the selected IPG page is not currently 

3 received at the terminal. 



1 20. The terminal of claim 18, further comprising: 

2 a memory unit configured to store a plurality of record elements, wherein 

3 each record element is associated with, and identifies, a respective IPG page received at a 

4 terminal. 

1 21. The terminal of claim 1 8, wherein each IPG page includes a plurality 

2 of defined regions, and wherein each record element identifies the one or more PIDs used 

3 to send one or more respective regions of the selected IPG page. 
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1 22. A system operable to provide information for an interactive program 

2 guide (JPG), wherein the IPG is provided via a plurality of IPG pages, the system 

3 comprising: 

4 a session manager configured to receive a request for a particular IPG 

5 page; and 

6 a transport stream generator coupled to the session manager and 

7 configured to 

8 assign a packet identifier (PID) for the requested IPG page, 

9 transmit the requested IPG page to a requesting terminal via the 
ID assigned PID, 

1 1 generate a record element indicative of the transmitted IPG page, 

12 and 

1 3 transmit the record element to the requesting terminal. 
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METHOD AND APPARATUS FOR KEEPING TRACK OF PROGRAM INDEXES IN 
AN INTERACTIVE DELIVERY SYSTEM 

ABSTRACT OF THE DISCLOSURE 

Indexing techniques to maintain track of IPG pages and allow a terminal to 
determine whether a selected IPG is currently received and available, which regions are to be 
assembled together to generate the selected page, and which packet identifiers (PIDs) are to 
be processed to recover the needed regions. In one method, a "roster" is formed which 
includes a number of record elements, with each record element being associated with and 
identifying a respective IPG page received at a terminal. Each record includes a page ID 
field that specifically identifies the associated IPG page. A number of fields may be included 
in each record element such as fields for a guide PID, a video PID, a data PID, and so on. 
The roster is updated to reflect changes in IPG pages received at the terminal. 
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TSG-to-Terminal Communication: 



Contents of Demand-Cast Index Table 



table version number (incremented when table content changes) 
list of available demand-cast streams 



IP address for the source TSG 



MUX channel number within the source TSG 



time-of-day and day-of-week 



FIG. 15A 



Termina!-to-SM Communication: 



Message Content 



demand-cast stream ID 



terminal ID 



IP address for the source TSG 



MUX channel number within the source TSG 



message information (acquisition, release, or request) 



FIG. 15B 
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SM to-TSG Communication: 



Message Content 



demand-cast stream ID 



MUX channel number within the source TSG 



message/command (stream released, stream requested, or reset) 



FIG. 150 



TSG-to-SM Communication: 



Message Content 



demand-cast stream ID 



MUX channel number within the source TSG 



IP address for the source TSG 



acknowledgement (of stream release, of stream request, or of reset) 



FIG. 15D 
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DECLARATION 

As a below named inventor, I declare that: 

My residence, post office address and citizenship are as stated below next to my name; I believe I am an 
original, first and joint inventor of the subject matter which is claimed and for which a patent is sought on the 
invention entitled: METHOD AND APPARATUS FOR KEEPING TRACK OF PROGRAM INDEXES IN 
AN INTERACTIVE DELIVERY SYSTEM the specification of which was filed on 11/08/00 as Application 
Serial No.Unassigned. 

I have reviewed and understand the contents of the above-identified specification, including the claims, as 
amended by any amendment referred to above. I acknowledge the duty to disclose information that is material 
to patentability as defined in Title 37, Code of Federal Regulations, Section 1.56. 

I claim no foreign priority benefits under Title 35, United States Code, Section 1 19. 

I claim the benefit under Title 35, United States Code, Section 119(e) of any United States provisional 
applications) listed below. 



Application No. 


Date of Filing 







I claim the benefit under Title 35, United States Code, Section 120 of any United States application(s) listed 
below and, insofar as the subject matter of each of the claims of this application is not disclosed in the prior 
United States application in the manner provided by the first paragraph of Title 35, United States Code, Section 
112, I acknowledge the duty to disclose material information as defined in Title 37, Code of Federal 
Regulations, Section 1.56 which occurred between the filing date of the prior application and the national or 
PCT international filing date of this application: 



Application No. 


Date of Filing 


Status 









I further declare that all statements made herein of my own knowledge are true and that all statements made on 
information and belief are believed to be true; and further that these statements were made with the knowledge 
that willful false statements and the like so made are punishable by fine or imprisonment, or both, under Section 
1001 of Title 18 of the United States Code, and that such willful false statements may jeopardize the validity of 
the application or any patent issuing thereon. 



Full Name of 
Inventor 2 


Last Name: 
GORDON 


First Name: 
DONALD 


Middle Name or Initial: 
F. 


Residence & 
Citizenship: 


City: 

Los Altos 


State/Foreign Country: 
CA 


Country of Citizenship: 

US 


Post Office 
Address: 


Post Office Address: 
170 Formway Court 


City: 

Los Altos 


State/Country: 
CA 


Postal Code: 
94022 


Signature 
& Date: 


Signature of Inventor : 


Date: 




Full Name of 
Inventor 1 


Last Name: 

EDMONDS 


First Name: 

JEREMY 


Middle Name or Initial: 

S. 


Residence & 
Citizenship: 


City: 

Castro Valley 


State/Foreign Country: 

CA 


Country of Citizenship: 

US 


Post Office 
Address: 


Post Office Address: 

18923 Sydney Circle 


City: 

Castro Valley 


State/Country: 
CA 


Postal Code: 
94546 


Signature 
& Date: 


Signature of Inventor : 


Date: 
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Full Name of 
Inventor 3 


Last Name: 

COMITO 


First Name: 

JOHN 


Middle Name or Initial: 
P. 


Residence & 
Citizenship: 


City: 

Redwood City 


State/Foreign Country: 

CA 


Country of Citizenship: 
US 


Post Office 
Address: 


Post Office Address: 

907 Pleasant Hill Road 


City: 

Redwood City 


State/Country: 
CA 


Postal Code: 
94061 


Signature 
& Date: 


Signature of Inventor ; 


Date: 




Full Name of 
Inventor 4 


Last Name: 

B AY RAKE RI 


First Name: 
SAD IK 


Middle Name or Initial: 


Residence & 
Citizenship: 


City: 

Foster City 


State/Foreign Country: 

CA 


Country of Citizenship: 

TR 


Post Office 
Address: 


Post Office Address: 

733 Shell Boulevard 
#104 


City: 

Foster City 


State/Country: 
CA 


Postal Code: 
94404 


Signature 
& Date: 


Signature of Inventor : 


Date: 
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